Run-time environments in which access control is based on stack inspection require that, when access to a protected resource is attempted at run time, all the callers on the call stack be granted the rights, or permissions, necessary to access that resource. Typically, permissions can be granted directly to the code accessing the resource, to the user executing that code or to both. A major challenge for code developers is the identification of the permissions their code will need at run time. Typically, the software developer writes the code and then determines the permissions needed by testing the code either dynamically or statically. The permissions that are not in the security policy associated with the code are observed. An absence of these permissions prevents successful execution of the program.
Test systems require a thorough or complete set of tests cases to provide the most accurate observation of the required permissions. A lack of a complete set of test cases causes permission requirements to be missed during testing. The consequence of missed permission requirements is system failure or unintended results at run time due to insufficient permissions being associated with the code. In order to avoid run-time authorization failures that can result from missing one or two permission requirements, a developer may recommend an overly broad set of permissions. Overly broad security permissions, however, violate security best practices such as the principle of least privilege and can result in security vulnerabilities.
As an alternative approach to dynamic testing procedures that require a large number of test cases to insure accuracy, static testing of the code can be used after the code has been written to determine what permissions are required. Even static analysis, however, can fail to recognize or uncover all of the permissions required by the code. Static analysis methods have been developed to increase the accuracy or completeness of the test. For example, in U.S. Pat. No. 7,076,804 a method is disclosed for conducting static analysis by using program graphs that represent the code being test. Permissions are associated with nodes within the graph, and the graph can be used to determine the permissions requirement by the code based on different execution scenarios. In U.S. patent publication no. 2003/0084324 a method is disclosed that utilizes object inheritance to assign permissions to code. The permissions are arranged in a hierarchy of classes and subclasses, and entire classes of permissions are assigned to the code.
Static analysis methods, however, still have shortcomings. In particular, in order to be precise, static analysis tools typically require several minutes, hours, or longer generating a complete permission analysis. Software developers, however, prefer to immediately know the authorization requirements of the code while they are creating or editing it. For example, an unexpected permission requirement in the code may reveal an unanticipated security problem in the code. Detecting that security problem right away allows for immediate code modification before permission requirements for other components are affected. For library code, some permission requirements should stay confined within the library code without propagating to clients of the library. For this to happen, the security-sensitive actions responsible for those permission requirements must be wrapped in a special language construct and made “privileged”. Detecting permission requirements during code creation affords the developer the ability to decide whether or not the security-sensitive action responsible for a permission requirement should be made privileged. In addition, explanations of why a specific permission is required can be useful for the developer as well as recommendations regarding a set of possible actions, e.g., code changes and security policy changes, that can be taken while editing the code.